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PLANNING FOR DBMS CONVERSIONS 


It is estimated that less than twenty percent of today’s mecha- 
nized data is stored in data bases, under the control of data base 
management systems (DBMS). But the rapid growth in sales of DBMS 
and related software (such as data dictionaries) leads one to believe 
that by 1985, this percentage will be much higher. Further, the or- 
ganizations that are using DBMS today are finding that they want to 
(or have to) upgrade to a new DBMs every few years. So conversions 
from non-DBMS to DBMS, or from one DBMS to another, will be very 
much a part of the near future workload for many computer users. 
Here is a summary of two working conferences that have aimed at 
developing management guides for these conversions. 


Mhaytora Roark, Executive Director of 
Systems for the Ford Motor Company, Dear- 
born, Michigan, was the keynote speaker at a 
working conference held last November and 
sponsored by the U. S. National Bureau of Stan- 
dards and the Association for Computing Ma- 
chinery. The title of the working conference was 
Data Base Directions, The Conversion Problem. 

This was the second such working conference 
on data base directions sponsored by NBS and 
ACM. The reports of the two conferences will 
be found in References 1a and 1b. For ease of 
reference, we will call the October 1975 confer- 
ence ‘DBD I and the November 1977 conference 
‘DBD Il’. 

As the keynoter at DBD II, Roark addressed 
the problems of converting to new hardware, op- 
erating systems, and DBM systems, based on the 
experiences at Ford. His company had recently 
made a catalog of its computer applications 
throughout the North American divisions. In to- 
tal, the survey catalogued some 50,000 computer 


programs, most of which used their own data 
files. Some of these data files were huge, mea- 
sured in billions of characters. A typical division 
of Ford, however, :is very much like a medium 
size business, said Roark; it might have between 
1500 and 3000 computer programs. 

While the survey did not explicitly study the 
amount of the data processing that is data base 
oriented, some clues were to be found in the cat- 
alog, Roark said. From these indications and 
from personal contacts elsewhere, he estimated 
this amount to be only 10% to 20% of the total 
data processing for U.S. industry as a whole. 
This indicates a much slower acceptance of data 
base technology than was expected five years 
ago. Roark saw several possible reasons why this 
was the case at Ford. : 

Some Ford divisions were saddled with a 
heavy system maintenance workload during the 
past five years. These divisions felt that they 
could not spare the resources that would be © 
needed for converting to a data base. 
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A few divisions had tried to convert to a DBMS 
and had run into conversions traumas. These di- 
visions had recovered from the difficulties but 
then decided that ‘once was enough.’ They did 
not undertake any more conversions to a data 
base during the five year period. 

Some other divisions had installed DBMS suc- 
cessfully and have continued to extend their use 
of data base technology. One Ford manager, per- 
haps the most enthusiastic advocate of data 
bases, told Roark that he thought about 40% of 
his division’s data was under DBMS control, after 
five years of development, and that by another 
five years, the amount might reach 70% to 80%. 

In general, Roark observed, the biggest obsta- 
cle to the adoption of data base technology is the 
historical accumulation of systems. If they could, 
most companies would like to get rid of their ‘old 
mess’ and start over. But the existing systems 
represent an investment of hundreds of millions 
of dollars at Ford, and many tens of billions of 
dollars for computer-using organizations collec- 
tively. “Where does even a moderate size com- 
pany with, say, 1500 to 3000 computer pro- 
grams, begin when converting to data base tech- 
nology, without having to scrap its investment in 
programs and data files?” he asked. 

But even if an organization does successfully 
install a DBMS and gradually extend its use, the 
conversion problem does not end there. Roark 
saw three continuing problem areas that are af- 
fected by the existence of the DBMS. 


Hardware conversion. Historically, the capac- 
ity of most data processing computers is satu- 
rated every three to five years and the computers 
are replaced. Roark cited three situations. In the 
first case, if the replacement involves a change to 


a new supplier, and if a DBMS has been used, then — 


a shift to a new DBMS probably will be required. 
Such a DBMS conversion may or may not be a 
problem, he said. One Ford division converted 
from a Honeywell computer, using IDS, to a 
Burroughs computer that used DMS II, two quite 
different systems. But these differences in the 
DBMSs did not materially affect the conversion 
effort. However, such smoothness cannot always 
be assumed, he added. 

In the second case, if the hardware change in- 
volves a switch to a new family of computers of 
an incumbent supplier, which seems to occur every 
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ten years or so, it is hard to say what trauma 
will be caused by the DBMS. This kind of 
change, involving a DBMS, has not yet happened 
at Ford. 

Finally, if the hardware change involves an 
upgrade within an existing family of computers, 
the existence of a DBMS has not been much of a 
factor in the conversion, Roark reported. 


Operating system conversion. Roark said that 
he expects major operating system upgrades or 
conversions from any one supplier every five to 
ten years, regardless of how ‘permanent’ the sup- 
plier claims the current operating system to be. 

As an example of such a conversion, the large 
Ford data center at Dearborn is undergoing a 
conversion to IBM’s MVS operating system. 
Three DBMS are in use: IMS, TOTAL, and Sys- 
tem 2000. Data and programs used with these 
DBMS have to be converted to run under MVS. 
The conversion of the IMS applications appears 
to be about twice as difficult as would have been 
the case if no DBMS were involved, he said. Fur- 
ther, while one manager saw benefits from IMS/ 
VS, another saw no advantages to his applica- 
tions from it, but he had to go along with the 
conversion because the old IMS would not be 
supported under MVS. 

The managers whose applications were run- 
ning under TOTAL and System 2000 encoun- 
tered no special conversion problems because of 
those DBMS, said Roark. 


Evolutionary application development. Roark 
reported that Ford’s use of computers was grow- 
ing at the rate of about 20% per year, measured 
in terms of billions of instructions executed. He 
estimated that about one-half of this growth was 
for new applications and the other half was for 
changes and enhancements to existing applica- 
tions. These changes and enhancements are 
needed because of new government regulations, 
changes in industrial standards, growth in pro- 
duct lines, corporate reorganizations, and efh- 
clency improvements. 

In theory, the existence of a DBMS should 
make the development of new applications and 
the changing of existing ones easier. In practice, 
the expected benefits can be hard to realize. Yes, 
changes can be incorporated more quickly and it 
is easier to develop new applications. Further, a 
DBMS greatly reduces the difficulty of making 


special analyses, since all of the needed data may 
be in the data base; previously, data might have 
to be drawn from five to ten different files with 
different maintenance cycles. But these benefits 
are obtained at a price. One study at Ford 
showed that some 70% of the instructions that 
were executed resulted from the DBMS overhead. 
In another instance, about half of the storage 
needed for a very large data base was consumed 
by pointers, far in excess of what was expected. 

As application systems are converted to a data 
base, or converted from one DBMS to another, 
some subtle and hidden problems can come to 
light such as those just described. Performance 
may be so far below expectations that a signifi- 
cant redesign effort may be needed. This, in 
turn, may discourage the conversion of other ap- 
plications to the data base. 

The realization of the promise of data base 
technology is still a long way off, concluded 
Roark. The payoff will come when the decision 
to go data base is no longer a high risk affair 
that requires an all-out commitment in order to 
solve some of the most difficult conversion prob- 
lems to be found in systems. 


Some ‘war stories’ 


Professor Edgar Sibley, of the University of 
Maryland, has been involved with data base 
technology for a number of years. Among his 
many computer field activities, he has been the 
chairman of the CODASYL Systems Committee. 
In a paper presented at the IFIP Congress 77 
last year in Toronto, he discussed some DBMS 
‘war stories.’ 

Difficulties encountered in installing DBMS 
are not well documented, said Sibley. The poten- 
tial authors may be intimidated by the DBMS 
suppliers. Also, the situations, if publicized, may 
be used ‘politically’ against data processing 
within the companies. Thus, the real-world ex- 
periences that Sibley discussed had to be well 
disguised, so the organizations could not be iden- 
tified. But the cases are real ones, he said. 

His contacts with many users of DBMS has led 
Sibley to one prime conclusion: There are hardly 
any technical problems involved with installing a 
DBMS, only people problems and managerial ones. 
Witness a case he described that had an abnor- 
mal complement of mistakes. 

In this case, to oversee the first application of 
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a newly acquired DBMS, the company selected a 
systems programmer who ‘could be spared’ and 
who was mainly interested in getting out of sys- 
tems programming. Not only was this choice of 
the key person poor but so was the choice of the 
first application. The implementation of that ap- 
plication took much too long and it was not use- 
ful after it was running. This experience con- 
vinced user departments at this company that a 
DBMS was inefficient and just another program- 
ming fad. Programmers, too, looked on the 
DBMS as inefficient and preferred to use ‘conven- 
tional access methods.’ 

Efforts to use the DBMS continued, and mis- 
takes continued. Some old card oriented and tape 
oriented application systems were converted to 
the data base without redesign. Records were ac- 
cessed by scanning through all records rather 
than by direct access. Little effort was made to 
develop common data definitions. Multiple, ap- 
plication oriented data bases were used, so that it 
was difficult to extract data for reports that drew 
from more than one data base. 

As might be expected, the DBMS was not 
looked upon as a panacea at that organization. 

At another organization, management ex- 
pressed an interest in an integrated data base to 
serve multiple applications. But for a number of 
reasons—such as managerial weakness, lack of 
commitment, or poor communications—some sig- 
nificant internal problems arose that caused 
resistance to the use of the DBMS. For one thing, 
programmers resented giving up the file design 
function to the data administrator. Systems pro- 
grammers felt that the ‘glamorous’ DBMS was 
displacing the operating system as the center of 
attention. User department people felt that they 
were losing control over ‘their’ data. Data 
processing management authorized the designers 
of one application system to use more system re- 
sources than the installation standards allowed; 
this led not only to resentment by the designers 
of other systems but also to a bad deterioration 
of on-line response time for all data base appli- 
cations. Finally, the top DP managers recognized 
that they were a part of the problem and started 
to learn about data base technology. ‘The com- 
pany gradually overcame these problems, but at 
a non-trivial cost in time and money. 

Sibley reported one manager as making a par- 
ticularly pertinent observation. “Don’t start the 


wrong way,” said this manager, “or it could take 
you ten years or an organizational crisis to 
change and do it right.” 

‘Doing it right’ requires the following, accord- 
ing to Sibley. First, a reasonably high level of 
top management acceptance and support is 
needed; a DBMS will cause important shifts in 
responsibilities. Second, use competent managers, 
to provide good management control of the DBMS 
project. Third, assign competent technicians, in- 
cluding a data administration staff, with proper 
tools. And finally, get competent auditors to 
monitor content, security, and privacy of the en- 
tire data base system. In addition, he recommen- 
ded that a data dictionary be installed before the 
first data base application is fully operational. 


How are DBMS being used? 


We are using the term “data base management 
system’ in this discussion in the context of a data 
base where the data is shared among multiple 
applications. Probably the first true DBMS was 
the General Electric MIACS system, developed 
for internal production control purposes by 
Charles Bachman in 1961. In 1963, this grew 
into the G.E. Integrated Data Store; (IDS is now 
offered by Honeywell Information Systems, 
Inc.). We are not including file management sys- 
tems, which are mainly being used to handle 
tape or disk application files. 

As indicated earlier in this report, probably 
less than 20%’ of today’s data processing involves 
true data base technology. Most computer users 
still have their data in application files stored on 
magnetic tape or on magnetic disk. When stored 
on disk, access to records is either done sequen- 
tially (as on tape) or by a conventional access 
method such as index sequential. 

A small percentage of computer using organi- 
zations have attempted to install a DBMS, have 
failed in the attempt, and have pulled back. Per- 
haps the wrong people were assigned to do the 
job, or the ‘politics’ was wrong, or the people 
tried to put in too sophisticated a system. What- 
ever the reason, these organizations are not anx- 
ious to try a DBMS again. 

Some other organizations have a percentage of 
their applications running under one or more 
DBMS, but with little or no sharing of data 
among the applications. ‘Data bases’ in these or- 
ganizations are much the same as application 
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files, and the DBMS is used as just a fancy new 
access method. If the data definitions for the tape 
and disk data files are not under control at these 
organizations, then chances are that the data 
definitions for ‘data base’ data also are not under 
control. The result is that there are duplications 
of data, inconsistencies, and so on, just as in the 
case of the older data files. 

A very small fraction of computer users have 
integrated data bases, serving multiple applica- 
tions from the same data base. These are the 
companies who are most likely to have the data 
definitions cleaned up. They also are the ones 
most likely to have installed the data administra- 
tor function, for controlling data definitions and 
file design. 

But even if a company is using a DBMS, 
whether on a shared data basis or not, one point 
is very generally true: only a small fraction of 
that company’s mechanized data is in the data 
base. Such a company might well have thousands 
of computer programs with their asssociated ap- 
plication files on tape or disk. The conversion of 
those programs and files to data base technology 
would involve a relatively large cost. Frequently 
there is no real incentive for making the conver- 
sion effort and expense. And in some cases, the 
applications are inherently stand-alone, with no 
possibility for sharing data with other applica- 
tions. 

Most of the above discussion of data base tech- 
nology has singled out the DBMS as ¢he main fea- 
ture of the technology. This is not actually the 
case. Let us now briefly consider the total data 
base environment. 


The total environment 


Enough use has been made by now of data 
base technology to get a good idea of just what is 
involved when an organization ‘installs a DBMS’ 
or ‘converts from one DBMS to another.’ Here 
are the elements that make up the total data base 
environment and that must either be installed or 
possibly changed, as pointed out at DBD II. 


Data definitions. In addition to the definitions 
of data fields and data records, data bases gener- 
ally involve explicitly defined relationships be- 
tween records to a greater extent than has been 
true in conventional files. So all data items and 
data relationships will have to be defined to the 


extent required by the DBMS. Further, if chang- 
ing from one DBMS to another, these definitions 
may well have to be changed. 


Data files. The data will have to be converted 
from the previous files (either mechanized or 
manual) to the data base, or from the old data 
base to the new one. Not only must the current 
data be considered but also the backup and ar- 
chival data. 


DBMS. This is the component that normally 
receives most of the attention. The new DBMS 
must be installed and whatever was used previ- 
ously must be phased out. 


Computer programs. Data independence is re- 
ally not yet within the state of the art. When the 
method of storing and retrieving data is changed, 
then the associated application programs usually 
must be changed. In fact, this might well be the 
biggest job in the conversion project. 


Data dictionary. Many users of data base 
technology have come to realize that they should 
have installed a mechanized data dictionary, to 
get their data definitions under control, before 
they installed a DBMS. Computer users who have 
not yet converted to data base technology should 
keep this point in mind. Converting to a DBMS 
ought to involve the installation of a data dictio- 
nary. Converting from one DBMS to another 
might require a change in data dictionaries, par- 
ticularly if one dictionary uses the DBMS it 
serves for managing the definition data. 


Query and report writing facilities. One of the 
benefits of a true data base is the convenience of 
answering ad hoc queries and report requests. So 
query languages and report writing languages 
have been developed, for use with data bases, 
and their use is growing rapidly. Further, users 
often develop catalogs of pre-defined queries and 
reports. These facilities are important elements 
of a data base environment. If the DBMS is 
changed, both the facilities and the catalogued 
queries and reports may well have to be 
changed. 


Data administrator function. Another thing 
that users of data base technology have learned is 
that they should have set up the data administra- 
tor function even before they installed a data dic- 
tionary, and have both installed prior to the in- 
stallation of the DBMS. This function controls the 


EDP ANALYZER, MAY, 1978 


data definitions and the structuring of the data; 
we discussed the function in our November 1972 
report. Converting from one DBMS to another 
may require a change in this function, perhaps 
because the new technology may be beyond the 
interests or capabilities of existing staff members. 


Security and integrity functions. Most com- 
puter users have recognized the need for data to 
be accurate, relevant, timely, and protected from 
destruction and unauthorized disclosures. New 
government regulations, such as privacy laws, 
raise the level of concern. Converting to a DBMS, 
or from one DBMS to another, may involve many 
associated changes in procedures to support data 
security and integrity. 

These, then, are the major elements that we 
view as making up the total data base environ- 
ment. They lead us into our next subject. 


How should DB technology be used? 


One has only to read the trade press to become 
aware of the growing use of data base technol- 
ogy. There are more and more advertisements 
for DBMS, for data dictionaries, for query and 
report writing packages that work with DBMS, 
and for network services that use data base tech- 
nology. Articles tell about user experiences. 
Classified ads seek people trained in these areas. 
And so on. 


In addition, data base technology is being ex- 
tended into the mini-computer and even the mi- 
cro-computer areas. Distributed data bases, us- 
ing minis, are almost (but not quite) here. The 
complexities of data base management are such 
that they stretch the capabilities of most of to- 
day’s minis, we believe, and are probably beyond 
the capabilities of today’s micros. Even so, we 
expect to see some aspects of data base manage- 
ment spreading among mini-computers and be- 
ginning to appear in some micros. (See Refer- 
ence 9 for information on one new CODASYL- 
type DBMS for some minis and micros.) 


As our discussion earlier in this issue pointed 
out, converting to data base technology is no sim- 
ple matter. Mayford Roark called it ‘the most 
difficult conversion problem of all,’ mainly be- 
cause of the historical accumulation of the pro- 
grams and data files that would have to be con- 
verted. But even if there is no attempt to convert 


existing systems, there are severe problems that 
can be encountered, as described by Sibley. 

What can computer users do to avoid the fail- 
ures and the messes? What is the best way to 
convert to data base technology for the first time? 
What steps can be taken to ease the conversion 
from one DBMS to another? 

To help answer such questions as these, the 
U.S. National Bureau of Standards and the As- 
sociation of Computing Machinery have jointly 
sponsored two working conferences with the ge- 
neric name Data Base Directions, as we men- 
tioned at the beginning of this report. Each 
working conference involved about 60 invited ex- 
perts, people working near the forefront of each 
sub-topic addressed by the conference. The goal 
of each conference was to produce a report of the 
conclusions of the working panels that addressed 
the sub-topics, based on two and one-half days of 
deliberations. The first working conference (DBD 
1) was held in late 1975, and DBD II was held in 
late 1977. References ta and 1b are the two re- 
ports. 

The working panels of DBD I addressed the 
subjects: user experiences with data base technol- 
ogy, future trends in data base technology, the 
need for data base standards, the expected im- 
pact of government regulations on the use of data 
base technology, and the impact of this technol- 
ogy on auditing. 

The topics addressed by the panels at DBD II 
included: user experiences with data base conver- 
sions, management considerations when making 
these conversions, how standards might help in 
conversions, and what conversion aids are being 
developed by the technology. 

So the two working conferences produced 
what we think is a good amount of practical ad- 
vice for management. The remainder of this re- 
port will summarize what was covered at the 
conferences, in an intermingled fashion. 


DATA BASE DIRECTIONS 


Our discussion of the two DBD working con- 
ferences will cover the keynote speech of DBD 
I, plus main recommendations of the working 
panels: user experience, management considera- 
tions, technology developments, the need for 
standards, the impact of government regulations, 
and the impact on auditing. 
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A manager’s viewpoint 


Daniel B. Magraw, the keynote speaker at 
DBD J, is Assistant Commissioner, Department of 
Administration, State of Minnesota. For nine 
years, he has been responsible for all aspects of 
the State of Minnesota information system activ- 
ities. He described the problems of introducing 
data base technology into an organization, from 
a manager’s viewpoint. 

The broad question of data management lies 
at the very center of the organization manage- 
ment process, said Magraw. The essence of man- 
agement is to rationalize decision making based 
on the best available data. So in dealing with the 
data of the organization, one deals with the heart 
and soul of management. 

Magraw sees eight areas of particular concern 
as one thinks of installing data base technology 
to manage the organization’s data resource. 
These areas are skewed heavily toward user 
management’s understanding and involvement. 


DBMS objectives. Why are computers not be- 
ing used more widely to support management’s 
decisions? As Magraw sees it, the fault is not 
with the technology but with the failure of man- 
agement to define the decision system so that the 
needs can be addressed. 

It is essential that management establish 
DBMS objectives, he said. Otherwise, the (ill de- 
fined) decision system can be adversely affected. 
“One simply does not fiddle around with the 
most precious of all raw materials of an organi- 
zation, its data. It is simply crucial that the tar- 
get be clear,” he said. 


Realism. In order to avoid the ‘Great Expecta- 
tions Cemetary, one must be realistic; be wary 
of over-stated claims. A data base system just 
will not go in overnight nor will it automatically 
save tremendous amounts of money. 


Organization. An unequivocal statement of re- 
sponsibility and a proper structure must be pro- 
vided for the data management function, or an 
expensive, academic exercise will result. The 
new organization should include strong, central, 
total authority over data definitions and related 
DBMS functions. 


Cost/ benefit. Management needs a clear cost/ 
benefit picture before deciding on installing data 
base technology. Consider all significant factors, 


said Magraw, including the non-hardware, non- 
software costs that are related to the organiza- 
tional, structural, and disciplinary changes that 
are needed. 


Transition. “1! am simply flabbergasted at the 
cavalier dismissal, by friend and foe alike, of the 
overwhelming prospect of putting the data bases 
in order for a DBMS.” The problems of getting 
good data definitions and data structures cannot 
be so easily dismissed, he said. 


Training. Insufficient training for computer 
professionals seems to center on the areas of de- 
cision theory, systems, and man-machine dialog, 
according to Magraw. But the greatest need is 
for management training in information systems 
in general and data base management systems in 
particular. 


Privacy. (Note: the State of Minnesota was a 
pioneer in the U.S. in the adoption of a privacy 
law, so Magraw has had first hand experience 
with this type of legislation.) New government 
regulations will affect the ability to collect data 
on individuals and to inter-relate such data from 
various sub-systems, he said. Since data base 
concepts tend to inter-relate data items, this will 
be an area of increasing concern. 


Security. “Can we justifiably expect greater 
security capability with data base technology? 
Do we become more vulnerable to some cata- 
strophic event?” These were only two of the 
questions raised by Magraw. In short, he says 
that there are still a number of unanswered 
questions about the security aspects of data base 
technology. 

As Magraw sees it, these and similar concerns 
should properly be addressed by user manage- 
ment, if the pitfalls of data base concepts are to 
be avoided and if the benefits are to be delivered. 


Management considerations 


Two types of conversions were considered by 
the panel (in DBD II) on management objectives, 
led by Richard Nolan. One type was converting 
from non-DBMS to DBMS, and the other type 
was converting from one DBMS to another. 
While there were some similarities between the 
two types, there were also some significant dif- 
ferences. 
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A general conclusion of this panel was a re- 
statement of a point made by Sibley in Reference 
2. That is, while it is appreciated that technolog- 
ical problems exist in data base conversions, it 
should be recognized that a DBMS conversion is 
primarily a management problem, for both execu- 
tive management and data processing manage- 
ment. 

The panel identified four key points for man- 
agement to keep in mind, regardless of the type 
of data base conversion involved. 


When, not whether. Management should rec- 
ognize that the problem of converting to data 
base technology is not one that will just ‘go 
away if it is ignored long enough. It is a ques- 
tion of when, not whether. The natural evolution 
of data processing 1s moving organizations into 
this environment. 

At the same time, the panel stressed that data 
base technology probably will not be suitable for 
all application systems, at least in the foreseeable 
future. Some applications will be more properly 
served by individual application files stored on 
tape or disk. 

When is data base technology likely to be 
adopted by an organization? The panel found it 
very helpful to use Nolan’s four stages of growth 
(Reference 3) for answering this question. Stage 
one is the getting started stage, when the first at- 
tempts are made to use a new technology. Func- 
tional areas are selected where the risks are not 
too great and where positive payoffs seem likely. 
Stage two is the proliferation stage—adding more 
functional areas and building on to existing ones. 
Both maintenance needs and overall costs grow 
to the point where it 1s hard to work on new ap- 
plications. Stage three is where management be- 
comes concerned with the rising costs and the 
‘mess’ that is being created. Control is imposed 
and clean-up is started. Finally, in stage four, a 
mature approach to the use of the new technol- 
ogy is reached. The organization is ready to be- 
gin using some even newer technology. 

To return to our question: when is an organi- 
zation likely to adopt data base technology? It is 
near the end of stage two that the need to get 
things under control becomes apparent. As an 
organization gets into stage three, data base tech- 
nology is almost a necessity, said the panel. 

Most computer using organizations are still in 


stage two. Proliferation in the use of computers 
has led these organizations to develop thousands 
of computer programs and thousands of applica- 
tion oriented data files. The ‘mess’ is now appar- 
ent. Some are beginning to move into stage three 
and to install data base technology. Many (or 
even most) new applications are being developed 
using data base concepts. But it will take a long 
time for all of the existing programs and data 
files to be converted to these concepts. 


Similarly, during stages three and four, DBMS 
users will find the need to convert from one 
DBMS to another, for any of a variety of reasons 
mentioned earlier in this report. Further, much 
more than just the DBMS will be involved, as we 
have indicated. The data files, the application 
programs, the data dictionary, etc. are also sub- 
ject to change. 


So these two types of conversions—to a DBMS 
and from one to another—are for all practical 
purposes inevitable. But we should reiterate: this 
does not mean that all applications need be on 
the data base. | 


Choose the entry application carefully. If the 
use of data base technology gets off to a bad 
start, it can delay the acceptance of this technol- 
ogy for a number of years. So it is very impor- 
tant that the first step be a good one. 


The first data base application preferably 
should be a non-trivial one, said the panel, but 
also a non-vital one. Recognize that this first ap- 
plication will be a learning experience. Once it is 
running, though, it should have good visibility 
for the user departments so that they can see the 
advantages of the data base. It should not be 
buried deep within data processing. 


By all means, said the panel, avoid the com- 
mon problem of trying to do too much with this 
first application. Do not try to demonstrate the 
‘full power’ of the DBMS by designing extra 
fancy data structures. 


However, the panel recognized that, in some 
instances, the only reason for putting in a DBMS 
may be to handle an application that is critical to 
the organization’s business. In such a case, the 
designers must be very careful to avoid a too- 
complex data structure. The combination of data 
base complexity and criticality is very risky and 
should be avoided. 
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Use good project management. Treat a DBMS 
conversion project like any other system project, 
said the panel. Use normal, good practices for 
justifying the project. Use good project manage- 
ment principles that cover the whole life cycle of 
the project, from justification through installation 
and maintenance (which we discussed most re- 
cently in our December 1977 report). Make sure 
the user department representatives play an im- 
portant role in the project management. 


Plan for future conversions now. The panel 
saw the use of data base technology as a way of 
life for the computer field. The first DBMS that 
an organization installs will be just that—the 
first of many. So it is not too soon to begin plan- 
ning on how to convert from one DBMS to an- 
other, even if the first one has not yet been in- 
stalled. 


The panel offered some management guides 
for this planning. Set up the data administrator 
function, with proper responsibility and with ad- 
equate authority over the data resources. Also, 
minimize the dependence of the application sys- 
tems on a specific DBMS, perhaps by building 
some in-house software to act as a standard in- 
terface between the application programs and the 
DBMS functions. 


Just how practical were these recommenda- 
tions by the management objectives panel? To 
see, let us now review what the user experience 
panels at DBD I and II reported. 


User experience 


The user experience working panels at both 
conferences included people from private indus- 
try and government who had gone through data 
base conversions. 


One of these panels thought that technologists 
view data base technology in terms of the ‘great’ 
things this technology can do—things such as su- 
perior access to data, easy multi-file processing, 
single source for data entry and edit, and on-line 
access for answering ad hoc queries. On the 
other hand, users tend not to view data base 
technology in this manner. Instead, users are 
puzzled by the new buzz words (such as 
‘schema’), they fear the total exposure and risk 
that a data base involves, and they are quite sus- 
picious of the claims for benefits that are made. 


Moreover, this panel warned against over-am- 
bitious starts in using data base technology. Such 
starts result in greater than necessary times and 
costs to implement the applications. Users may 
be (inadvertently) encouraged to ask for more 
than they need because of the great promise of 
the technology. Then, when problems are en- 
countered, alientation of users and management 
occurs. 

So instead of an overly ambitious start, plan to 
deliver small data base oriented systems in a 
short time frame. Build up confidence among the 
users in what the technology can do for them. 
Pay particular attention to designing forgiving 
and fault tolerant procedures for terminal opera- 
tors, for each new data base application. And do 
not attempt to give full access to all data base 
data from the outset. 

The other panel on user experience made 
many similar observations. Take a phased ap- 
proach to implementing a data base; such an ap- 
proach is easier to contro] and more likely to 
succeed. Design the data base so as to minimize 
the impact on other existing systems. In general, 
do not attempt to write the DBMS software in- 
house. 

Future developments in technology are not 
likely to obsolete any significant portion of the 
effort to use data base concepts effectively. So 
there is really no need to wait ‘until the tools are 
perfected.’ Today’s technology provides adequate 
tools with which to get started. 

At the two working conferences, attended by 
people who had been working deeply in the data 
base area, much the same theme was repeated 
over and over again. This theme was: Take it 
easy. Take small steps. Have realistic expecta- 
tions. Treat a data base project like any other 
system project. Start now to make future con- 
verions easier. 

But how about the new technological develop- 
ments? Surely, with all of the progress that is 
being made in the computer field, there must be 
some exciting developments on the horizon. Will 
not these developments make conversions to data 
base concepts much easier? These were the types 
of questions addressed by the two panels that 
dealt with technology. 


Technology 
The members of the technology panels at the 
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two working conferences were drawn from 
among people who are working at the forefront 
of data base concepts, on developments that have 
not yet reached the marketplace. So these people 
were in an excellent position to know just what 
is likely to appear in the next few years. 


At DBD I, the panel concluded that new types 
of data base architecture were to be expected in 
the not-distant future. One such architecture was 
the back-end computer that would handle data 
base management, in much the same way that 
front-end computers now handle data communi- 
cations functions. The distributed data base was 
recognized as an as-yet unsolved technical area, 
but the panel expected to see commercially avail- 
able distributed data base systems by 1981. 


The flow of new data models is expected to 
continue, said this panel. These models provide 
the means by which data ‘models’ the real-world 
relationships. The better known models include 
the CODASYL approach, the hierarchical model, 
and the relational model. Panel members were 
experienced with developing most of the leading 
models and were aware of their strengths and 
weaknesses. 


Then came what we considered to be one of 
the more significant observations of the confer- 
ence: “Each of these models has proponents who 
point to advantages for their model and suggest 
that these models are decisive. However, the 
panel saw no ‘best model’; further, it will be 
hard to conclude which model is best within the 
next five years. We recommend that the user se- 
lect the model that presently best fits immediate 
and near future problems. In terms of expected 
advantages, presently proposed new models are, 
at best, evolutionary rather than revolutionary.” 


Considerable progress was expected to occur 
in the area of data independence, wherein appli- 
cation programs are independent of certain types 
of changes made to the data definitions. Progress 
was also foreseen in improved facilities for recov- 
ering data bases from failures. But no ‘great 
breakthrough’ was foreseen, that would make 
conversions to data base technology much easier. 


(We might add that in the interim, since DBD 
I was held, what has actually happened in data 
base technology is very much in line with what 
the panel expected to happen.) 


Conversion technology 


The technology panel at DBD II concentrated 
on conversion tools. Panel members included 
people who have been working on some of the 
most advanced conversion tools, to aid in convert- 
ing from tape or disk files to a data base, or to 
aid in converting from one DBMS to another. 


What the panel concluded was that technology 
today can address only a small fraction of the 
overall problem. The problem is complicated by 
the thousands of poorly documented programs 
and thousands of undefined data items at the 
typical computer using organization. 


Data and program conversion are never-end- 
ing problems, the panel observed. The need to 
convert is caused by new technology becoming 
available (or by a dissatisfaction with inadequate 
old technology), by new user requirements, and 
by new functions to be performed. 


The use of data base standards can help ease 
these conversion problems. But standards will 
not eliminate the problems. 


Automated tools to help perform conversions 
are, today, limited both in their number and in 
their capability. The most successful conversions 
have been ones that have used teams of people 
who are experienced in performing conversions; 
further, these teams generally use manual tools 
and techniques. 


However, some automated tools are on the ho- 
rizon. For instance, the data translator being de- 
veloped at the University of Michigan will read 
a source data base, translate the logical relation- 
ships of the data according to prescribed rules, 
and then write the target data base. But the 
translator does not change the application pro- 
grams to work with the new data base, and the 
panel saw this program conversion problem as 
more difficult than the data conversion. Also, the 
translator will not handle changes from one 
brand of hardware to a dissimilar brand. 


What can be done to reduce conversion prob- 
lems? The panel made some recommendations. 


General recommendation. Make a controlled 
and intelligent use of today’s technology. There 
are tools and techniques available now that can 
help, if they are used intelligently. But none of 
them are ‘magic formulas’ that guarantee suc- 
cess. 
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Define the data. One of the most basic things 
that should be done is to explicitly define and 
document the data definitions and data relation- 
ships. An automated data dictionary can help get 
the data definitions under control, particularly 
within one line of equipment. Do not allow user 
maintained data relationships to be continued, 
where the users ‘know’ that certain data items or 
files are related. All relationships should be de- 
fined explicitly and maintained in the dictionary, 
to as great an extent as practical. 


Select from current techniques. A good data 
base design will reduce the need to restructure 
the data base, so search out good design tech- 
niques. Good program design methods provide 
stable, maintainable modules. Develop in-house 
program/data interfaces and use them in the ap- 
plication programs; if the DBMS is changed, only 
the interface routines (probably) will have to be 
rewritten and not the application programs. Bind 
all parameters at execution time and not at com- 
pile time. 

The defining of data, the design of the data 
base and application programs, and the building 
of stable program/data interfaces are all part of 
today’s technology. If used intelligently, said the 
panel, they can materially aid the conversion ef- 
fort. 


Conversion is a user responsibility. “Let the 
vendor do our conversion” is a risky approach, 
the panel observed. The vendor almost certainly 
will limit the project to a straight conversion and 
would do no redesign. But redesign may well be 
essential, because the data structures in the new 
data base may be so different from the structures 
used previously. Conversion really cannot be del- 
egated; the user organization must assume re- 
sponsibility for it. 


Develop and use standards. The technology 
panel at DBD I expressed concern about the effect 
of standards on emerging technology. But the 
panel at DBD II advocated a continued develop- 
ment of standards. If technology gets too far 
ahead of standards, said this panel, it may be- 
come a hopeless task to try to develop the stan- 
dards. The panel also pointed out the problem of 
getting installation standards accepted across or- 
ganization boundaries. 

The value of standards is often not appreci- 
ated by senior management, so there may be no 
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great motivation on the part of management to 
adopt standards. It is up to the technologists to 
point out how conversion and operations can 
benefit from the use of intelligent standards. 
Which raises the question: just what is the 
status of data base standards? A panel at each of 
the working conferences addressed this question. 


Standards 


At DBD I, the standards working panel 
pointed out that data base standards must em- 
brace more than just the DBMS; the standards 
should cover the various aspects of data base us- 
age. Moreover, such standards are an interna- 
tional concern and responsibility, and their de- 
velopment should be coordinated on an interna- 
tional basis. 

The panel saw the need for four types of stan- 
dards. Terminology standards are needed to pro- 
mote understanding and learning. Criteria stan- 
dards are needed for use in evaluating proposed 
data base standards because of the variety of in- 
terests involved. Component standards are needed, 
for data elements, data definition languages, data 
manipulation languages, and so on. Finally, ws- 
age standards are needed to protect the integrity 
of the data bases. 

This standards panel also made a significant 
observation. As far as a DBMS standard is con- 
cerned, the CODASYL proposal was (and still is) 
the only candidate submitted for possible stan- 
dardization. No other candidate has been for- 
mally entered. Since it takes well over five years 
for a proposal to go through the standards 
process, the only likely standard in the next few 
years is the CODASYL approach. 

The panel at DBD II stressed that the compo- 
nents of a standard DBMS should be delineated, 
indicating what the standard DBMS should con- 
sist of. ‘The component standards should tell 
what logical features are to be provided, not how 
they will be provided, in order to provide flexi- 
bility for evolving technology. Further, there well 
may be a need for multiple DBMS standards, not 
just one, for serving different needs. 

While it probably will not become a ‘stan- 
dard, the panel strongly urged that the good 
practice be followed of installing a data dictio- 
nary and getting the data definitions under con- 
trol before installing a DBMS. 

Recognize, too, said this panel, that there will 
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be a spectrum of standards. The spectrum in- 
cludes installation standards, federal standards, 
national standards, and international standards. 


Government regulations 


This working panel, at DBD I, included repre- 
sentatives familiar with state and federal infor- 
mation systems. They sought to predict which 
regulations then in existence or expected would 
relate to information systems, and what the 
likely impact of those regulations might be. 

The panel identified twenty areas for which it 
believed government regulations will come to ex- 
ist nationwide, affecting both public and private 
sectors. The seven existing or anticipated regula- 
tions with the greatest expected impact appear to 
be the following: (1) Regulations that say the 
system must prohibit all data accesses except 
those specifically authorized. (2) Regulations re- 
quiring that information systems be certified that 
they meet all specified regulatory requirements. 
(3) Regulations that define a data subject’s rights 
of access to information about him. (4) A stan- 
dard DBMS for federal use. (5) Regulations spec- 
ifying that certain types of applications must use 
dedicated data processing systems (example: 
criminal records systems). (6) Regulations on the 
accuracy, completeness, and timeliness of per- 
sonal data held in information systems. And (7) 
regulations specifying that a log of all changes 
and disclosures of sensitive data be maintained. 

The panel identified and discussed thirteen 
other possible regulations, but the above seven 
seemed to us to have the greatest expected im- 
pact. 

The panel felt that the use of a DBMS might 
well make it easier to respond to new regula- 
tions, or to changes in regulations. But a DBMS 
also brings with it the risk of chaos if the single 
source of data (the data base) is destroyed. 

The responsibility imposed upon data process- 
ing management will increase as the number of 
new regulations increases. Managers will have to 
determine that the hardware, software, and pro- 
cedures will indeed carry out the intent of the 
regulations. Further, any penalties imposed for 
failure to comply adequately with the regulations 
might fall most heavily on individuals in data 
processing. 

How does management determine if the data 
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is being used and handled properly? ‘That ques- 
tion was addressed by the audit panel. 


Auditing 


Auditors have always been concerned about 
control, security, and integrity in (financial) in- 
formation systems. How does the advent of the 
data base affect this concern? The panel con- 
cluded that the roles of internal and external au- 
ditors will not change in a data base environ- 
ment, but there will be a shift in emphasis on 
what an auditor must perform. This shift may 
involve the certification that regulations are be- 
ing met, as raised by the government regulations 
panel. 

Just what differences might data bases bring 
about in auditing? Here are some of the observa- 
tions. 


Security. As a general principle, auditors rec- 
ommend the separation of duties in the handling 
of assets and liabilities. A data base makes con- 
trol more difficult because it aggregates data 
rather than fragmenting it by application. An in- 
dividual might be able to access a wide variety of 
company records and manipulate them for his or 
her own purposes. 


Integrity. Auditors are concerned with errors 
of input and with file integrity. In a non-data 
base environment, the same transaction often 
serves as input (in different formats) to two or 
more application systems. It is possible to com- 
pare records to determine sources of input errors. 
But with a data base, transactions are entered 
only once and this facility is lost. Also, erroneous 
transactions detected during input validation 
may be destroyed, rather than just tagged and 
saved. An auditor may feel this to be a loss of 
useful information. 


In the area of file integrity, it has been postu- 
lated that someday a company that is wedded to 
an integrated data base will lose all copies of that 
data base (through some form of destruction) 
and will have to go out of business. In fact, there 
have already been a few near misses. When a 
case of ‘fatal corporate amnesia’ does occur, there 
will be a lot of finger pointing, and the auditors 
may have to share some of the blame. In fact, a 
fair case can be made that the auditors will share 
in the blame if they did not give clear warnings 
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of the risk of corporate amnesia, even if the 
probability was small. 


Accountability for data. With application ori- 
ented files, it is fairly easy to identify the person 
or the group responsible for inputting and main- 
taining each data field. With a shared-use data 
base, the responsibility is not so clear. It should 
be specifically assigned (and probably in writ- 
ing). In a data base environment, the responsibil- 
ity might be much stricter than has been true in 
non-data base systems. 


Asset value. The data base, as the repository 
of much corporate data, will be a valuable asset. 
It should be subjected to strict security and con- 
trol procedures, probably to a greater extent than 
has been true in non-data base environments. 


Data definitions. Because of the sharing of 
data, all data definitions will have to be ‘stan- 
dardized’ and coordinated. Where this in fact is 
done, it will improve the control over the data 
definitions. 


Audit independence. In a data base, the logical 
structure of the data may be quite different from 
the physical structure in which it is stored. So 
the auditor will probably have to use access 
methods provided by someone else, in order to 
access the data. Thus, the independence of the 
auditor will be reduced. 

These were only some of the points (but the 
ones that stood out most in our mind) raised at 
the two working conferences. 


Conclusion 


Back in June 1973, our report dealt with ‘the 
cautious path to the data base.’ In it, we urged 
users to take small, easy steps in converting to 
data base technology. The two working confer- 
ences on Data Base Directions, sponsored by the 
National Bureau of Standards and the Associa- 
tion for Computing Machinery, have stressed the 
same points, and in much more detail. 

Let us conclude with a repetition of the admo- 
nitions. Get your data definitions cleaned up Je- 
fore you install a data base. Use a data dictionary 
to get the data definitions in shape. Take it easy 
for your first DBMS application. Pick a non-triv- 
ial but also a non-vital application for your first 
efforts. Have realistic expectations; a DBMS will 
not go in overnight and it will not save bundles 
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of money. Treat the data base project like any 
other system project, using good project manage- 
ment methods. And start now to take the steps to 
make future data base conversions easier—be- 
cause data and program conversion are a never 


ending problem. 
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